NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/12199

Internet Message Format | 1996-08-05 | 3.6 KB

Path: gisdev.genasys.com.au!not-for-mail
From: [e-mail] (Robert Swan)
Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
Subject: Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
Date: 19 Mar 1996 07:32:51 +1100
Organization: Genasys II, Australia
Message-ID: <4ikh9k$[e-mail]>
References: <[e-mail]> <3taaha$[e-mail] <64ss5$[e-mail]> <4ijmup$[e-mail]>
NNTP-Posting-Host: gisdev.genasys.com.au

In article <4ijmup$[e-mail]>,
john p radigan <jradigan@davinci> wrote:
>Joachim Durchholz ([e-mail]) wrote:
>: I haven't said a word of design phase vs. programming phase. And my
>: impression is indeed that a hacker doesn't want to waste time on design
>: when he could use to build working programs. But that is more a question
>: of the point of view; the hackers that build large systems do design in an
>: informal way, and they usually don't document it. Nevertheless all larger
>: programs done by hackers have a design.
>
>I don't think it's a point of view, the evidence is usually in the code
>itself.  Even without a formal design specification beforehand, the quality
>of output seperates the truely dangerous code-first mentality from the ones
>who had a clear understanding of the problem before they ever fired up the
>editor.
>
>: And on the design side, I have seen hours spent on design meetings, put
>: the results into specifications - only to discover two weeks later that
>: the specifications were utter sh*t. Such incidents don't exactly encourage
>: hackers to spend time on design.
>
>That's short-sighted at best, a thoughtful person can seperate the process of
>design from the poor leadership that resulted in a useless specification.

I'm puzzled how this comes down to bad leadership, but no matter.

I used to believe that you should complete a design prior to
doing any coding...  right down to completing user documentation
etc.  Unfortunately, this approach has failed me more often than
not.  You usually end up with a great solution to the wrong
problem.

Here's the typical formal analysis procedure:

1. Gather user input
2. Show user specification, as you have understood it.
3. Refine specification according to user feedback
4. Once the spec. is satisfactory, code it.

For me, step 3 is the Achilles heel.  Despite my best efforts to
explain the specification to them, and their assurances to the
contrary, the "users" don't understand the specification well
enough to see the potential repercussions of various design
decisions.  So we end up agreeing on a wrong spec, doing step 4
and _then_ get useful feedback from the same users saying that
the didn't expect this or that limitation was going to be there.

This experience has forced me down from the moral high ground of
academic idealism.  I am now quite happy to use a quickly coded
example (using any language -- perl, sh, C) to show the users
what the final implementation might look like: i.e. a prototype.
The thing that allows me to hold my head up in public and admit
this is that _this_ code is only used in step 3.  It is all ripe
for discarding; just as soon as the users are happy with what
they're going to get.  We can then get on and code meticulously,
and with considerably more confidence that we're not going down a
blind alley.

It works for me anyway.

Have fun,

Robert.
--
Robert Swan,                         |  No, not the Antarctic adventurer.
[e-mail]               |  No, not the Canberra porn monger.
Genasys II Pty. Ltd., North Sydney.  |  Yes, that's right.  The boring one.